Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex, and, for that matter, not very realistic either. Therefore, Xconq includes several levels of automation for human players.
The elements of automation are the task, the plan, the doctrine, and the strategy. These are related to each other by goals.
Tasks are single activities of a unit that require one or more actions to accomplish. Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport. Most of the commands that you give while playing actually set up tasks rather than individual actions.
A plan is the unit's object that expresses its decided-upon behavior. Elements of a plan include a type, possibly one or more goals, a task agenda, plus some assorted flags and properties. All units that can act and that are on a side will have a plan, while independent units that can do actions may have a plan that is preset by a scenario. Plans primarily govern individual behavior, in many cases allowing the unit to act on its own, without needing any explicit direction from the player.
The doctrine is the set of parameters governing how the side will play and how its units should work generally. For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.
The strategy and associated subobjects is what an AI uses to make all the decisions about what to do. This object is not directly visible, unless the AI is acting as your assistant and the interface includes a display of its strategy.
Of all these types of objects, only the doctrine can be manipulated directly; all others are implicitly changed as a result of player commands, which are different for each interface.
The Standing order command allows you to set up conditions for execution of tasks.
There is a doctrine for each type of unit on your side. Several types may share a single doctrine, so that changes to it will affect all types equally.
[more doctrine info]
A unit's plan must be one of the types listed here.
none
).
Units with this type of plan do absolutely nothing.
passive
).
Units with a passive plan will execute any tasks they have
been given, but will not add to the task agenda on their own.
By default, if you are running the side by yourself,
with no AI assistant, your units will have this type of plan.
offense
).
Units with an offensive plan will look for favorable
combat opportunities, usually within an area specified as their goal
to hold.
defense
).
Units with a defensive plan will seek to preserve the status quo.
explore
).
Exploratory units will seek to collect information about
unknown parts of the world.
A task has several standard properties and may have additional properties specific to the task's type. Xconq keeps track of how many times a task has been executed and how many times it has failed to execute a step correctly. For example, a movement task to a distant location may need to execute 100 times, but it will only fail if the unit is actually blocked from moving. If a task fails too many times, the plan or the AI may decide to remove the task from its agenda. If a task succeeds, it will always be removed.
Each task in a plan's task agenda must be one of the types listed here.
none
).
sentry turns
).
Stand sentry at the present location for a given number of turns.
This is not the same as sleeping, since it is for a definite period
of time.
move-dir direction
).
Move in the given direction up to the given distance.
move-to location
).
Move to within a given distance of the given location.
occupy unit
).
Move towards a given unit and attempt to enter it.
pickup unit
).
Move towards the given unit and wait for it to enter.
build unit-type n
).
Build a given number of units of a given type.
This task will do research actions if necessary and possible,
and toolup actions if necessary.
Also, if there is an incomplete unit of the given type
nearby, this task will complete it before creating a new unit.
research unit-type n
).
Do research to increase the tech for a given type
up to a given level.
hit-position location
).
Attempt to attack or fire on any units at the given position.
hit-unit unit
).
Attempt to attack a given unit.
capture location
).
Attempt to capture a unit at a given location,
optionally of a given type and on a given side.
resupply material-type
).
Replenish depleted supplies.
This may be accomplished by production actions,
moving to higher-productivity terrain,
or by moving within supply range of a unit with the desired
supplies.
repair unit
).
Repair damage to the given unit.
do-action action-parms...
).
Standing orders are basically a combination of a test or condition and a task to be performed when the condition is met. The textual form of the command is "if <type> <test> <task>", where <type> is a name of a unit type, <test> is some sort of condition, and <task> is a task, as described previously.
Possible tests include at location
, in unit
,
and near location dist
.
The at
test applies to the unit if it comes to be in a particular cell,
for whatever reason. The location may be either a comma-separated pair
of coordinates, or the name of a unit.
The near
test is similar to at
, but you give an additional
argument that says how close, in cells, the unit must be for the order to apply.
For instance, a distance of 1 means that the order applies to units at the
given location and to all adjacent units. This is useful if you want to
have several kinds of units use a rendezvous point that is on a type of
terrain that some of the kinds can't use, or if there are stacking limits
and requiring all units to converge on a single cell would result in
traffic jams.
The in
test applies to the unit if it is an occupant of the given
unit.
If a unit is already performing another task, it will ignore any standing orders in any location that it happens to be passing over; so it is not possible for the standing order to waylay the unit and send off doing something else. The unit must be under your orders ("passive" plan), not have any tasks on its agenda, and cannot be asleep or in reserve.
if armor in Paris move-to Antwerp if bomber in London move-to 33,54 if bomber at 33,54 hit-position 34,60
The second example shows how you can use several standing orders together to route units around obstacles or dangerous areas.